The invention is related to the concepts of safety, or more concretely functional safety, and safety-related systems. Safety is defined “as the absence of catastrophic consequences on the user(s) and the environment” [1] or “the freedom from unacceptable risk of physical injury or of damage to the health of people, either directly, or indirectly as a result of damage to property or to the environment” [2]. Functional safety is defined as “the part of the overall safety that depends on a system or equipment operating correctly in response to its inputs” [2] or similarly as an “absence of unacceptable risk due to hazards caused by mal-functional behavior of electrical and/or electronic systems” [3].
A safety-related system is defined as a system “necessary to carry out one or more safety functions, where failure of the safety function would give rise to a significant increase in the risk to the safety of persons and/or the environment” [2]. Safety-related data is the data necessary for the execution of safety functions, such that if (some of) these data are compromised a particular safety function would fail.
Some commercial off-the-shelve microcontrollers provide execution environments for safety-related (e.g. ISO26262:2011, IEC 615/08) software. Such environment is typically characterized by a hardware memory protection mechanism, which separates different software components from each other. It ensures that memory areas containing safety-related data are protected and can only be accessed by the safety-related software and such separates the safety-related software from the non-safety-related software.
Another mechanism to ensure a correct data processing of safety-related software is to use two redundant processor cores executing the same operations and comparing the results of their computations. If such computations are performed with a defined time delay, this mode is known as lockstep mode of operation and the cores are called lockstep cores. Safety execution environment typically also contains self-checking and advanced diagnostic features.
In many cases, such safety-related software needs to ensure integrity of static (never/infrequently modified) data, e.g. configuration data. Data integrity can be compromised by e.g., memory malfunction, cosmic radiation, or manufacturing defects.
One state-of-the art method of ensuring data integrity is to pre-calculate a CRC value of this data as a reference value once, and then re-do the calculation periodically to check if the CRC value is still equal to the reference value [4]. For safety-related data, these calculations are performed on safety-related an execution environment using safety-related software. When the data, e.g. configuration data, is large, this calculation can be very time consuming, which is especially true for embedded systems. For example, when the requirement is to check the data integrity every 20 ms, but the check itself consumes 15 ms, then the software spends 75% of its runtime for the integrity checks, making the device almost useless for real applications.
Many embedded microcontrollers have a built-in hardware engine, e.g. a hardware accelerator engine, for CRC calculations, which could free the CPU from the long-running CRC calculations. However, such CRC engines (also called “non-safety-related hardware-engine”) are not capable to provide a CRC in the safety-level required by safety-related applications.